Alarm system ip network with pstn output

ABSTRACT

Alarm customers on VoIP may use an adapter for conversion to Internet Protocol (IP) signals or may have an alarm system that uses IP signals to transmit alarm signals over the Internet. IP signals from alarm customers may go to any monitoring center for alarm system monitoring. IP signals from alarm systems using IP conversion equipment can go only to monitoring centers with specialized receiving equipment specific to the type of transmitting equipment in use at the customer&#39;s premises. There is a pool of customers, whose dealers would convert to IP and stay with the current monitoring center if the center invested in receiving equipment. For the many small centers who will not or cannot invest in receiving equipment, the present invention will take IP signals from any or all brands of IP transmitting equipment, to a central server then retransmit to any center over POTS to the alarm monitoring center. Thus, an alarm monitoring center need not invest in a number of different IP monitoring systems in order to be IP monitoring compliant.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is also a Continuation-In-Part (CIP) ofco-pending U.S. patent application Ser. No. 13/004,917 (ELLIOT-0010)filed on Jan. 12, 2011 and incorporated herein by reference; applicationSer. No. 13/004,917 is a Continuation-In-Part application of U.S. patentapplication Ser. No. 12/018,724 (ELLIOT-0008), filed on Jan. 23, 2008and incorporated herein by reference, which in turn is aContinuation-In-Part of U.S. patent application Ser. No. 11/517,025(ELLIOT-0007), filed on Sep. 7, 2006, and incorporated herein byreference; which in turn is a Continuation-In-Part of U.S. patentapplication Ser. No. 11/226,857 (ELLIOT-0005) filed on Sep. 14, 2005 andincorporated herein by reference; application Ser. No. 11/226,857 inturn claims priority from Provisional U.S. Patent Application Ser. No.60/651,662 (ELLIOT-0004) filed on Feb. 11, 2005 and incorporated hereinby reference; application Ser. No. 11/226,857 is also aContinuation-In-Part (CIP) of co-pending application Ser. No. 10/861,790(ELLIOT-0003), filed on Jun. 7, 2004, and incorporated herein byreference; application Ser. No. 11/226,857 is in turn aContinuation-In-Part of U.S. patent application Ser. No. 10/840,280(ELLIOT-0002) filed on May 7, 2004, and incorporated herein byreference, which in turn is Continuation-In-Part of U.S. patentapplication Ser. No. 10/462,708 (ELLIOT-0001) filed on Jun. 17, 2003,(now U.S. Pat. No. 7,245,705) and incorporated herein by reference,which in turn claims priority from Provisional U.S. Patent ApplicationSer. No. 60/389,960 (ELLIOT-0001P), also incorporated herein byreference; The present application is also a Continuation-In-Part (CIP)of co-pending U.S. patent application Ser. No. 12/504,709 (ELLIOT-0009)filed on Jul. 17, 2009 and incorporated herein by reference; applicationSer. No. 12/504,709 is also a Continuation-In-Part (CIP) of U.S. patentapplication Ser. No. 11/348,291 (ELLIOT-0006) filed on Feb. 6, 2006, nowU.S. Pat. No. 7,734,020 and incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates towards alarm and security systemmonitoring. In particular, the present invention is directed towardalarm system monitoring over the Internet, and more specifically with atechnique for allowing alarm system monitoring companies that do nothave Internet alarm monitoring capabilities to monitor alarm systemsthat communicate over the Internet, by providing a telephone output forconventional alarm monitoring equipment.

BACKGROUND OF THE INVENTION

In recent years, alarm systems are moving toward monitoring over theInternet, and the present inventors, as evidenced by the number ofpatents previously incorporated by reference, have developed a number oftechniques relating to Internet monitoring of alarm systems, includingdevices for converting conventional alarm systems to IP protocols, usingVoIP and other techniques. Other alarm systems may be configured tointerface directly with the Internet, through a wireless (WiFi) ornetwork connection (e.g., plugging into a router, cable modem, DSLmodem, or the like).

One problem with Internet monitoring of alarm systems is that there area number of such IP alarm systems or converters (such as developed bythe present inventors) on the market, and each may have its ownparticular format and central station monitoring hardware or software.If an alarm monitoring company wishes to monitor signals from a numberof different brands or formats of equipment, it must invest in differenthardware and software for each brand and type of equipment. Moreover,since such alarm monitoring systems may be “stand alone”, the alarmmonitoring company may have to maintain and monitor such separatesystems, meaning that the monitoring personnel have to monitor andrespond to multiple screens of data, each in a different format andusing a different command and menu structure—and each requiring separatetraining.

Many smaller monitoring companies may not want to invest in new IP-basedalarm equipment, but instead prefer to use their older POTS (Plain OldTelephone Service) or PSTN (Public Switched Telephone Network)interface. Such smaller alarm companies may find themselves unable tocompete with larger companies, particularly as more and more customersswitch to VoIP or IP based alarm protocols.

Thus, it remains a requirement in the art to provide a means formonitoring centers to be able to receive IP based alarm signals usingexisting equipment, and receive alarm signals on a single type of alarmmonitoring equipment, without having to purchase and operate separatealarm monitoring systems for each equipment type and brand.

SUMMARY OF THE INVENTION

Alarm customers on VoIP may now use an adapter developed by the presentinventors, for conversion to IP (Internet Protocol) as disclosed inApplicant's previous patent applications previously incorporated byreference. In the present invention, IP signals from customers can go toany monitoring center—those with corresponding servers on IP directlyand those without corresponding servers, using the central server(middleware provider) of the present invention to dial on POTS (PlainOld Telephone Service) to the monitoring center or by communicatingdirectly with the monitoring center over an IP link. IN this manner, themiddleware server can take a number of alarm signals from disparatealarm system types, formats and paths (IP or POTS) and output them in asingle format, which may be used by the alarm monitoring company. In oneparticular embodiment of the present invention, IP signals aretranslated back into POTS signals, such that an alarm monitoring companyusing POTS equipment can monitor IP alarm signals.

Traditionally, IP signals from alarm systems using IP conversionequipment (or IP based alarm systems) could only be sent to monitoringcenters with specialized receiving equipment specific to the type oftransmitting equipment in use at the customer's premise. There is a poolof customers, whose dealers would convert to IP and stay with thecurrent monitoring center if the center invested in receiving equipment.

For the many small centers who will not or cannot invest in receivingequipment, the present invention takes IP signals from any or all brandsof IP transmitting equipment, to a central server at a middlewareprovider which may then retransmit to any center over POTS or otherformat. The middleware server may also provide a suite of notificationservices also editable by the customer or dealer using a customerportal.

Thus, it is one objective of the present invention to convertnon-standard and varied format IP signals to single standard signal,including a POTS signal, for delivery to a monitoring center, includinga Prior Art POTS-type monitoring center.

Alarm system manufacturers are producing alarm equipment designed totransmit alarm data over the Internet. While there is a standardprotocol available it is rarely used. Consequently there are severalsystems in use each requiring specialized server receiving equipment atthe alarm monitoring center. Many smaller alarm monitoring centers willnot purchase or cannot afford the servers for the different systems. Thepresent invention allows IP transmissions from many different systems tobe decoded at our server farm and the transmitted to alarm monitoringcenters in one format, including via POTS.

This allows any alarm monitoring center to accept signals from allprotocols that the server farm has available. The decoding serversessentially become a shared resource. The current VoIP Alarm platformwhich provides a user portal with SMS, IVR, email notifications andalarm history may also be provided to users.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of the IP to PSTN alarm translation system ofthe present invention.

FIG. 2 is a flow chart illustrating the steps in the IP to PSTN alarmtranslation method of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The alarm translation system of the present invention is discussed belowin connection with FIGS. 1 and 2.

One key to understanding the present invention is that in the alarmmonitoring business, alarm monitoring companies and the companyproviding the alarm services may be two different entities. Thus, forexample, if a customer contracts with ACME Alarm Systems Company foralarm services, ACME may in turn subcontract out the actual day-to-daymonitoring of the customer's alarm system to a third party—perhaps evenoffshore—where operating costs are lower. The Alarm company may providea branded identity (ACME) to the customer, as well as service(installation, repair) of the physical alarm system, billing services,and also middleware services, as described elsewhere in applicant'sprevious applications incorporated by reference.

However, Prior Art alarm systems use a number of formats to generate andtransmit alarms, from early POTS (Plain Old Telephone Service) systemswhich would “dial out” on a PSTN (Public Switched Telephone Network)line, to newer systems, which may connect directly to the Internet or beconfigured to connect to the Internet as follows.

As previously noted, alarm systems may be modified or designed to sendalarm signals over an IP link to an alarm monitoring center or to amiddleware provider. FIG. 1 is a block diagram of the IP to PSTN alarmtranslation system of the present invention. Referring to FIG. 1, anIP-enabled alarm panel 1 may transmit an alarm signal over the Internet,via cable modem, DSL modem, router, or other internet connection 2. Notethat for purposes of this application, an IP-enabled alarm panel 1 mayinclude an alarm panel designed to generate IP signals (e.g. though anEthernet output) or a Prior Art alarm system converted to IP capabilityusing the VoIP techniques or other techniques of the present inventors.

At a server 3, an IP to PSTN translator receives the IP protocol alarmsignals from the internet connection 2 and looks up the correctmonitoring company or station to call (based on a look-up table ordatabase having alarm system identification information, to correlatealarm identification information with the correct monitoring station orcompany). The server then picks up a PSTN line and dials the receiver ofa traditional central station and conveys the alarm signal usingstandard PSTN protocols. A receiver at the central station (monitoringcompany) receives the signals at a receiver 5 and decodes the PSTN alarmsignal and conveys it to a dispatch system 5. Dispatch system 5 maycomprise a Prior Art PSTN based alarm monitoring system which may bemonitored by an individual. The individual may then see the alarm systemcodes and identification and take the normal steps in dispatching thealarm (calling the consumer to confirm false alarms, dispatching Policeor Fire or Emergency personnel, and the like) as in the Prior Art.

In this manner, a Prior Art alarm monitoring company may receive alarmsignals even from modern IP-based or converted alarm systems. The server3 may be located at a middleware provider, who contracts with theconsumer to provide alarm monitoring services, and in turn sub-contractsout the alarm monitoring services to the alarm monitoring companyhousing central station 5. Alternately, an Alarm monitoring companyhousing central station 5 may employ a middleware provider with server3, in order to offer IP Alarm customers their monitoring services,without having to invest in new monitoring equipment.

In an alternative embodiment of the present invention, server 3 mayreceive IP signals from various alarm panels 1, which are in a number ofdifferent IP Alarm system formats and coding. Server 3 may then convertthese codes into a standard format which in turn may be communicated toan alarm monitoring center 5 via PSTN connection 4, as illustrated inFIG. 1, or using an Internet connection. In this embodiment, numerousdifferent Alarm IP formats may be converted by the middleware providersuch than an alarm monitoring center need only have one type of centralstation monitoring equipment using one type of alarm coding protocols.In this manner, the middleware provider can act as an alarm systemtranslator, taking a number of different alarm codes (both IP and POTS)and providing them to the monitoring station in a format desired by themonitoring station.

FIG. 2 is a flow chart illustrating the steps in the IP to PSTN alarmtranslation method of the present invention. Referring to FIG. 2, theprocess starts in step 800. In step 810, an alarm signal may begenerated by an alarm panel, such as the IP-enabled alarm panel 1 ofFIG. 1, or a conventional alarm panel (POTS output). Note than alarmsignals may include actual alarm signals (break-in, fire, flood, smoke,glass breakage, door or window alarms, panic alarms, or the like) or mayinclude other signals, such as maintenance and monitoring signals andperiodic update signals.

In the preferred embodiment of the present invention, the alarm panel isan IP enabled alarm panel, meaning that it generates an IP signaldirectly to the middleware server, as illustrated by the connection tostep 830. Alternately, the alarm panel may convert a POTS signal to anIP signal using a VoIP technique or other conversion technique 820 suchas disclosed in the present application or applicant's previousapplications incorporated by reference. This converted IP signal maythen be sent to the middleware server in step 830. In addition, themiddleware server may be configured to accept POTS signals directlythrough an input POTS line, although this is not the preferredembodiment of the present invention. However, the overall idea behindthe present invention, as illustrated in FIG. 2, is to accept alarmsignals from a number of different types and models of alarm systems,using different formats and signal paths, and then output these signalsin a single, common format over a single signal path, as will bediscussed below in more detail.

In step 840, the alarm signals, having been received in differentformats, are reformatted at the middleware server. Applicant'smiddleware server and processes have been described in more detail inthe applications incorporated by reference and the details are notdescribed here for the purposes of brevity and clarity. Data fromincoming signals (e.g., alarm panel serial number, incoming phonenumber, IP address or other indicia) are used to identify the customerand the alarm system type. From this data, the alarm signal may bereformatted into a common, single format. Thus, for example, IP signalsfrom a number of different manufacturers may be reformatted to anindustry standard alarm signal format or a single proprietary format.The desired output format may be determined by the format desired by themonitoring company, which may possess equipment accepting one or moreparticular formats.

This form a may include a legacy POTS format favored by older alarmcompanies and monitoring companies. If an IP format is selected, thissignal may be sent via Internet directly the monitoring company in step870. In step 850, middleware functions may be performed. Again, thesefunctions have been described in applicant's previous applicationsincorporated by reference. These functions include, but are not limitedto, notifying a customer directly via cell phone, SMS, Internet, orother means, and allowing the customer to cancel the alarm at themiddleware stager, or otherwise interface and interact with the alarmsystem. These middleware functions may be optional, depending on thenature of the alarm company and also whether the customer paid for suchservices, which may be offered a la carte or as part of an alarmmonitoring package.

If the alarm monitoring center accepts IP signals, these signals may besent directly to the center via internet as illustrated by theconnection between step 850 and 870. In step 860, if the alarm signalsare to be sent in POTS format over a PSTN, the middleware server maydial out to the alarm center and transmit the alarm signals in POTSformat using one of the known POTS alarm formats known in the art, or aformat accepted by the monitoring center.

In step 870, the alarm signals are received by the monitoring center ina format acceptable to the monitoring center's existing equipment.Regardless of whether the monitoring centers uses antiquated POTSequipment, or modern IP-based equipment, the present invention iscapable of interfacing with both types (and the several varieties ofeach). In this manner, a middleware provider can offer alarm monitoringservices and then contract out the actual alarm monitoring to the alarmmonitoring service that is most cost-effective, without having to forcethe alarm monitoring center to upgrade its equipment or change formats.For the middleware provider, changing alarm monitoring centers is simplya matter of reprogramming the output to the desired input format of themonitoring center. In this manner, the middleware provider can offer acentral, branded, alarm service, and change monitoring centers in aseamless manner that is transparent to the end user.

In step 880, the alarm monitoring center receives the alarm messages inthe usual manner. To the alarm monitoring center technicians andmonitoring staff, the entire process is transparent—the incoming signalsappear to be in the same format as all other incoming alarm signals, andthe brand and type of alarm system used by the customer is irrelevant—asis the mode of communication of alarm signals—IP or POTS.

The alarm monitoring center may then perform its usual functions—callingfire, police, or other emergency services, or calling the customer toconfirm whether a false alarm has been triggered. From both the customerand alarm center monitoring point of view, the entire transaction istransparent and works as if the customer's alarm was tailored to thealarm monitoring center's equipment. However, since the presentinvention provides middleware translation, neither the customer nor thealarm monitoring center need purchase new equipment, unless desired.

Thus, the present invention allows an alarm service provider (middlewareprovider) to achieve greater customer penetration and more conquestsales, as they can now offer to monitor a customer's alarm system withlittle or no alteration in the hardware used by the customer. And thealarm service provider can provide superior service and lower prices bybeing able to choose among a variety of alarm monitoring companies to dothe actual alarm monitoring—and be able to switch from one to another atwill (or use multiple companies) without having to swap out hardware ateither end. In this manner, the middleware provider is not married toone company and thus cannot subject to arbitrary price hikes or the likeby the monitoring company. In addition, the middleware provider canchange alarm monitoring companies if the service from the alarmmonitoring company is less expected.

While the preferred embodiment and various alternative embodiments ofthe invention have been disclosed and described in detail herein, it maybe apparent to those skilled in the art that various changes in form anddetail may be made therein without departing from the spirit and scopethereof.

1. A method for converting an alarm signal in a first format to an alarmsignal in a second format, using a middleware server, the methodcomprising the steps of: generating, at a customer's alarm system, acustomer alarm signal in a first format, transmitting the customer alarmsignal to the middleware server, receiving, at the middleware server,the customer alarm signal, converting, a the middleware server, thecustomer alarm signal in the first format to a monitoring center alarmsignal in a second format, transmitting from the middleware server, tothe alarm monitoring center, the monitoring center alarm signal in asecond format, receiving at the alarm monitoring center, the monitoringcenter alarm signal in a second format, displaying, at the alarmmonitoring center, the monitoring center alarm signal in a second formatas an alarm signal message.
 2. The method of claim 1, where in the stepof generating further comprises the steps of: generating a customeralarm signal in a POTS (Plain Old Telephone Service) format to produce aPOTS customer signal; converting the POTS customer signal to an IPsignal using a VoIP (Voice over Internet Protocol) converter; andoutputting the customer alarm signal in the first format, where thefirst format comprises an IP (Internet Protocol) signal.
 3. The methodof claim 1, wherein the step of generating comprises the step ofgenerating a customer alarm signal in a POTS (Plain Old TelephoneService) format wherein the first format comprises a POTS signal.
 4. Themethod of claim 1, where in the step of generating further comprises thesteps of: generating a customer alarm signal in an IP signal format,where the first format comprises an IP (Internet Protocol) signal. 5.The method of claim 1, wherein the step of converting further comprisesthe steps of: looking up a customer number derived from the customeralarm signal, in a database, determining customer alarm system type, andmonitoring center for the customer, and converting the customer alarmsignal in the first format to a monitoring center signal in the secondformat, based on alarm type and monitoring center for the customer. 6.The method of claim 1, wherein the customer alarm signal in a firstformat comprises an Internet Protocol (IP) alarm signal, and themonitoring center alarm signal in a second format comprises a PublicSwitched Telephone Network (PSTN) alarm signal.
 7. The method of claim1, further comprising the steps of: looking up a customer number derivedfrom the customer alarm signal, in a database, determining whether acustomer has elected to be directly notified of a customer alarm signal,and transmitting, from the middleware server to the customer, a signalindicating that a customer alarm signal has been generated.
 8. A methodfor monitoring an alarm system generating Internet Protocol (IP)messages, using an alarm monitoring station receiving Public SwitchTelephone Network (PSTN) messages, comprising the steps of: generating,at a customer's alarm system, a customer alarm signal as an IP message,transmitting the IP message over an internet connection to a server,receiving, at the server, the IP message, converting, a the server, theIP message into a PSTN message, calling, from the server, to an alarmmonitoring center, using a PSTN phone line, connecting the server to thealarm monitoring center using the PSTN phone line, and communicating thePSTN message to the alarm monitoring center.
 9. The method of claim 1,wherein the step of converting further comprises the steps of: lookingup a customer number in a database, determining customer alarm systemtype, and converting the customer alarm signal to a PSTN message basedon alarm type.
 10. An alarm system for converting an alarm signal in afirst format to an alarm signal in a second format, using a middlewareserver, the system comprising: at least one customer's alarm systemgenerating a customer alarm signal in a first format, a communicationlink transmitting the customer alarm signal to the middleware server, amiddleware server receiving the customer alarm signal, a converter inthe middleware server converting the customer alarm signal in the firstformat to a monitoring center alarm signal in a second format, a secondcommunication link transmitting from the middleware server, to an alarmmonitoring center, the monitoring center alarm signal in a secondformat, the alarm monitoring center, receiving the monitoring centeralarm signal in a second format, a display at the alarm monitoringcenter displaying the monitoring center alarm signal in a second formatas an alarm signal message.
 11. The system of claim 10, where in thecustomer's alarm system further comprises: a legacy alarm panelgenerating a customer alarm signal in a POTS (Plain Old TelephoneService) format to produce a POTS customer signal; and a VoIP converter,converting the POTS customer signal to an IP signal using a VoIP (Voiceover Internet Protocol) converter and outputting the customer alarmsignal in the first format, where the first format comprises an IP(Internet Protocol) signal.
 12. The system of claim 10, wherein thecustomer's alarm system further comprises a legacy alarm panelgenerating a customer alarm signal in a POTS (Plain Old TelephoneService) format wherein the first format comprises a POTS signal. 13.The system of claim 10, where in the customer's alarm system furthercomprises: an IP signal generating alarm panel generating a customeralarm signal in an IP signal format, where the first format comprises anIP (Internet Protocol) signal.
 14. The system of claim 10, wherein themiddleware server further comprises: a database looking up a customernumber derived from the customer alarm signal, in a database, and aprocessor programmed to determine customer alarm system type, andmonitoring center for the customer, and convert the customer alarmsignal in the first format to a monitoring center signal in the secondformat, based on alarm type and monitoring center for the customer. 15.The system of claim 10, wherein the customer alarm signal in a firstformat comprises an Internet Protocol (IP) alarm signal, and themonitoring center alarm signal in a second format comprises a PublicSwitched Telephone Network (PSTN) alarm signal.
 16. The system of claim10, wherein the middleware server further comprises: a database lookingup a customer number derived from the customer alarm signal, in adatabase, and a processor program to determine whether a customer haselected to be directly notified of a customer alarm signal, andtransmit, from the server to the customer, a signal indicating that acustomer alarm signal has been generated.